Hey @erezrokah, all very fair points. I was taking a shortcut to do the bare minimum possible to get it working with next.js - i.e. in a context where there is no app with .post or .use methods, so traditional middleware basically isn't supported. But yes it does mean there's no schema validation, cors, json-parsing or logging. Those were all ok to miss because respectively, the client is only sending valid requests, we happen to not need cors, next.js has already done json-parsing for us, and we are able to do our own logging.

I think I could probably make it work with the existing exports by passing in a fake express app from the handler, but that would be quite brittle.

An alternative - could the dist folder be generated using tsc rather than webpack? Given it's a node library/CLI I can't see why it would need to be bundled or minified. There'd be a few benefits:

• users could import from dist/middlewares/whatever, at their own risk
• type declarations would come for free
• no need to maintain the webpack config anymore! (This is only a benefit because you already have a tsconfig, otherwise you'd be swapping one for the other)

Update: got it working with the existing exports by passing in a fake app. Behold the hoop-jumping:

export default async (req, res) => {
  const netlifyCmsProxyServer =
    require('netlify-cms-proxy-server/dist/middlewares') as typeof import('netlify-cms-proxy-server/src/middlewares')
  const path = require('path')
  const handlers: Function[] = []
  process.env.GIT_REPO_DIRECTORY = path.join(process.cwd(), '../..')

  const fakeApp = {
    use: () => {}, // skip next.js 
    post: (_path: string, handler: Function) => handlers.push(handler),
  }
  
  await netlifyCmsProxyServer.registerLocalFs(fakeApp as any, { logLevel: 'error' })
  
  for (const handler of handlers) {
    let nextCalled = false
    const next = () => (nextCalled = true)
    await handler(req, res, next)
    if (!nextCalled) {
      break
    }
  }
}

The above could easily break if the library changes some parts of its implementation, so I'd still be in favour of exporting the extra functions. But I might play around with a tsc build alternative instead.

Closing in favor of #5856. I do believe using tsc is the right approach, given that we don't break existing consumers (we'll need to verify).